IP Security (IPsec) standard, IP Security Internet Engineering Task Force (IETF) Request for Comments (RFC) 2401, published November 1998, is one method of protecting both the confidentiality and integrity of data transferred on a network. Because IPsec provides a way to encrypt and decrypt data below the Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) layer, the protection is transparent to applications that transfer data. Thus, a system may utilize IPsec without requiring changes at the application level. However, the algorithms used for cryptography (crypto) operations (e.g., encryption, decryption, authentication) on the data for IPsec require many processor cycles to execute. The processor cycles spent on crypto operations decrease the cycles available to applications and other parts of the protocol stack. This in turn decreases throughput in the system.
One solution to this problem is to offload the crypto operations to an external piece of hardware, such as a Network Interface Card (NIC). One way to offload the crypto operations is by encrypting data immediately before transmitting a packet and decrypting data directly from the wire before the packet is transferred via Direct Memory Access (DMA) to host memory. A Security Association (SA) is a data structure of cryptography information that contains all of the information necessary to perform crypto operations on a packet. The device that interfaces the system to the network, for example a NIC, detects which SA is needed to process the packet and performs crypto operations on the packet directly from the wire. The process for performing crypto operations on ingress data before it is transferred to host memory is called “Inline Receive.”
Another solution is to offload using the “Secondary Use” model. This model uses an out-of-band acceleration method to decrypt receive packets. In this scenario, all received packets are DMA transferred to host memory. The network interface driver then parses each received packet to match it with its corresponding Security Association (SA). Assuming that the crypto accelerator is on the NIC, the driver then instructs the NIC to transfer the packet across the bus, perform the crypto operation on the packet, and then transfer the packet back to host memory. Secondary Use results in inefficient use of the available bandwidth on the system bus because the packet is transferred across the bus three times. Secondary Use also creates additional latency, which can degrade the throughput of protocols sensitive to the round trip time of packets (e.g., TCP). Furthermore, performing the extra transfers across the bus often requires the use of an additional interrupt, causing the system to do more work, and increasing CPU utilization.
The network interface driver must determine which traffic streams will be handled using Inline Receive, and which traffic streams will be handled using either Secondary Use or software processing. A traditional approach is to add SAs to the Inline Receive cache on a first come, first served basis. Under the traditional approach, packets associated with SAs in the cache will be handled using Inline Receive. Once there are no available entries in the cache, packets for non-cached SAs must be handled using either Secondary Use or software processing.
From a performance perspective (both processor utilization and throughput), Inline Receive is a more efficient solution than Secondary Use. On the other hand, Inline Receive is expensive to implement in hardware because the SAs necessary for the crypto operations must be stored in an SA cache on the NIC. Because of this, the number of connections that can use Inline Receive is often limited. Because it is common for the number of open connections to exceed the size of the Inline Receive cache, the other connections must use the Secondary Use model in order to offload secure traffic.